\subsection{Généralités}
Le standard EMV est apparu en 1994 à l'initiative de 3 compagnies Europay\texttrademark, MasterCard\texttrademark et Visa\texttrademark. EMV est un standard d'inter-opération de circuits intégrés pour cartes. Il constitue désormais la norme choisie pour assurer l'interopérabilité entre les terminaux de paiement (TPE) et les cartes de paiements à puce.
Ce standard définit les interactions physiques, électriques, les niveaux données et applications entre les cartes et les terminaux de paiement en ligne(TPE).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{L'avant EMV}
Le protocole de paiement par carte bancaire utilisé dans les années 90 comportait des faiblesses qui avaient été dénoncées dès 1988 par Louis Guillou dans son article "Techniques à clé publique" \cite{publickey}. Cependant ces failles ne seront exploitées qu'en 1998 par Serge Humpich qui va créer les "yescard", qui sont des répliques de cartes de crédit.\\

A cette époque, la sécurité du paiement reposait sur le secret autour du protocole et l'impossibilité de créer la réplique d'une carte. En procédant à la rétro-ingénierie d'un terminal, Serge Humpich est parvenu à comprendre le protocole. De plus, les clés RSA utilisées par le protocole ne comportaient que 320 bits. La puissance des ordinateurs de l'époque était alors suffisante pour les factoriser. Il devenait dès lors possible de trouver la clé privée nécessaire, comme nous allons le voir, au chiffrement des données inscrites dans la carte.

\subsubsection{Fonctionnement de l'ancien protocole}
Les agents impliqués dans ce protocole sont :\\
$T$ le terminal, $C$ la carte, $A$ comme Alice le détenteur de la carte, $PK$ la clé publique chiffrement et $SK$ la clé privé banque.\\
Les données manipulées sont :\\
le nom, le prénom, le numéro de carte, la date de validité, la signature de ces données avec la clé privée que nous noterons $\{data\}_{SK}$. Ces données ainsi que la signature sont enregistrées sur la carte au moment de son initialisation.

\subsubsection{Déroulement de la transaction}
La transaction se déroule en hors-ligne, c'est à dire que tout se passe entre la carte et le terminal; seule la puce est utilisée pour faire les vérifications.
\begin{enumerate}
\item $T \longrightarrow A $ : "authentification".
\item $C \longrightarrow T $ : $data$, $\{data \}_{SK}$. (le terminal utilise la clé publique $PK$ pour extraire "$data$" de la signature et les comparer aux "$data$" envoyées par la carte)
\item $T \longrightarrow A $ : code? 
\item $A \longrightarrow T $ : 1234 (par exemple)
\item $T \longrightarrow C $ : 1234
\item $C \longrightarrow T $ : ok.
\end{enumerate}

\textbf{Faille n\textsuperscript{o} 1 :} en recopiant les données publiques "$data$" et la signature ${data}_{SK}$ de la carte valide sur une carte à puce vierge puis en ajoutant un programme qui renvoie toujours la valeur ok quel soit le code PIN qu'introduit l'utilisateur, la transaction s'effectue correctement! 
\pagebreak

\textbf{Faille n\textsuperscript{o} 2 :} plus grave encore, il est possible d'utiliser des données crées de toutes pièces et grâce à la clé privé $SK$ qui a pu être trouvée (voir ci-dessus), d'en effectuer la signature. Il est alors possible de construire une yescard avec ces deux données forgées et en ajoutant le programme renvoyant ok quelque soit le code PIN saisi :
\begin{enumerate}
\item $T \longrightarrow A$ : "authentification"
\item $C \longrightarrow T$ : $data$ fabriquées, $\{data\}_{\{SK\}}$    le terminal valide cette étape
\item $T \longrightarrow A$ : code ?
\item $A \longrightarrow T$ : 7777 (par exemple)
\item $T \longrightarrow C$ : 7777
\item $C \longrightarrow T$ : ok.
\end{enumerate}


Serge Humpich effectua une démonstration de la validité de sa "yescard" en retirant un carnet de tickets de métro dans un distributeur automatique.

\subsection{Description}
L'ISO 7816-3 définit le protocole de transmission entre la puce de la carte et le lecteur. Une transaction EMV suit les étapes suivantes : \\

\textbf{Étape n\textsuperscript{o} 1 : Sélection de l'application} \\ 
Les émetteurs de cartes(Visa, Mastercard...) sont identifiés par un "registered application provider identifier"(RID).
Ils ont leur propres applications qui définissent leurs produits, par exemple Visa a la Visa credit, la visa electron, 
la v pay...Ces applications sont représentées par une "application identifier"(AID).\\

\textbf{Étape n\textsuperscript{o} 2 : Initier le traitement de l'application}\\
Le terminal et la carte s'échangent des données, en particulier, la carte envoie l' "application interchange profile"(AIP), une liste de fonctions à exécuter pendant le traitement de la transaction. La carte fournit aussi l' "application file locator"(AFL), une liste de fichiers et d'enregistrements dont le terminal à besoin pour lire la carte.\\

\textbf{Étape n\textsuperscript{o} 3 : Lecture des données de l'application}\\
Les cartes stockent les données dans les fichiers. L'AFL contient les fichiers dans lesquels se trouvent les données EMV.\\

\textbf{Étape n\textsuperscript{o} 4 : Traitement des restrictions}\\
Le but de cette étape est de savoir si la carte peut être utilisée. Trois données lues dans l'étape 3 sont contrôlées :
\begin{itemize}
\item le numéro de la version de l'application
\item le contrôle d'usage de l'application (ceci indique si la carte est pour un usage domestique...)
\item le contrôle des dates usage/expiration de l'application.
\end{itemize}
Si l'un de ces contrôles échoue, la carte n'est pas nécessairement rejetée. Ceci permet par exemple aux possesseurs de cartes périmées de continuer à les utiliser mais uniquement pour des transactions en ligne.\\

\textbf{Étape n\textsuperscript{o} 5 : Authentification des données hors-ligne}\\
L'authentification des données hors-ligne est un moyen de contrôle sur la validité de la carte utilisant la cryptographie. Il y a 3 différents modes d'authentification :
\begin{itemize}
\item le "static data authentication" (SDA) s'assure que les données lues sur la carte ont bien été signées par l'émetteur
de la carte. Ceci évite la modification des données mais pas le clonage de la carte.
\item le "dynamic data authentication" (DDA) fournit une protection contre la modification des données et du clonage.
\item la combinaison DDA/"generate application cryptogram" (CDA) combine le DDA avec la génération de cryptogramme d'application pour s'assurer de la validité de la carte.\\
\end{itemize} 

\textbf{Étape n\textsuperscript{o} 6 :  Vérification de l'identité du détenteur de la carte}\\
La vérification du détenteur est mise en oeuvre pour vérifier si la personne présentant la carte est le détenteur légitime. Il y a beaucoup de méthode de vérification "carholder verification methods" (CVMs) supportées par EMV :
\begin{itemize}
\item signature
\item hors ligne, PIN en clair
\item hors ligne, PIN chiffré
\item hors ligne, PIN en clair et signature
\item hors ligne, PIN chiffré et signature
\item en ligne, avec PIN
\item pas de CVM requis
\item traitement de CVM ayant échoué \\
\end{itemize} 

\textbf{Étape n\textsuperscript{o} 7 :  Gestion du risque par le terminal}\\
Le "terminal risk management" est uniquement mené dans les dispositifs où il y a une décision à pendre pour faire une transaction hors-ligne ou en ligne. Si les transactions sont toujours menées en ligne ou toujours hors ligne, cette étape est ignorée. Le terminal contrôle le montant de la transaction qu'il compare à une limite (au delà de laquelle les transactions se font en ligne). Si le résultat de l'un de ces tests est positif, le terminal fixe un bit approprié dans le "terminal verification results" (TVR). \\

\textbf{Étape n\textsuperscript{o} 8 : Analyse de l'action par le terminal} \\
Les résultats de l'étape précédente sont utilisés pour déterminer si une transaction est approuvée hors ligne, envoyée en ligne pour autorisation, ou refusée hors-ligne.\\

\textbf{Étape n\textsuperscript{o} 9 : Première analyse d'action par la carte}\\
En fonction du résultat de l'étape précédente, le terminal va réclamer l'un des cryptogrammes suivants à la carte :
\begin{itemize}
\item "transaction certificate"(TC) pour une approbation hors-ligne
\item "authorization request cryptogram"(ARQC) pour une autorisation en ligne
\item "application authentication cryptogram"(AAC) pour un refus hors-ligne
\end{itemize}
Cette étape donne l'opportunité à la carte d'accepter l'analyse d'action du terminal ou de refuser une transaction ou de forcer une transaction en ligne. \\

\textbf{Étape n\textsuperscript{o} 10 : Autorisation de transaction en ligne}\\
Les transactions vont en ligne quand un ARQC a été demandé, celui-ci est généré par la carte et il dépend de l'application de la carte. Cette demande fournit un solide contrôle cryptographique pour vérifier que la carte est authentique. L'émetteur de la carte répond à l'ARQC avec un code de réponse, une "authorisation response cryptogram" (ARPC) et éventuellement un script (commandes envoyées à la carte). \\

\textbf{Étape n\textsuperscript{o} 11 :  Seconde analyse de la carte}\\
Après une autorisation de transaction en ligne, la carte a besoin de recevoir des données (ARQC par exemple). Si pour une raison quelconque (coupure de courant...), le terminal n'a pas pu conserver la ligne, celui doit tenter de renvoyer à la carte ces données. La seconde analyse va permettre à la carte de connaître la réponse de l'émetteur de carte.\\

\pagebreak

\textbf{Étape n\textsuperscript{o} 12 :  Traitement du script de l'émetteur}\\
Si un émetteur de carte veut mettre à jour une carte, il peut le faire au moyen de scripts. Les scripts destinés à la carte sont chiffrés, ils sont donc incompréhensibles pour le terminal. Ces scripts peuvent changer les paramètres de la carte ou bloquer complètement la carte.


\subsubsection{Documents et standards}

Depuis la version 4.0, les documents officiels définissant EMV ont été publiés dans 4 livres et documents complémentaires :
\begin{itemize}
\item livre 1 : \textit{Application independent ICC to terminal interface requirements}
\item livre 2 : \textit{Security and key management}
\item livre 3 : \textit{Application specification}
\item livre 4 : \textit{Carholder, attendant and acquirer interface requirements}
\item \textit{Common payment application specification}
\item \textit{EMV card personnalisation specification}
\end{itemize}

La première version, EMV 2.0, est apparue en 1995.\\
La version 4.0 en juin 2004\\
La version 4.1 en juin 2007\\
la version 4.2 en juin 2008.

\subsection{Vulnérabilités}

\subsubsection{Clonage de la carte}

\subparagraph{Principe d'authentification avec mode SDA}
Les agents intervenant dans ce mode sont :\\
T le terminal, C la carte, A ou Alice le détenteur de la carte, $PK$ la clé publique de chiffrement, $SK$ clé privé de la banque, $PK_A$ la clé publique de l'autorité de certification, $SK_A$ la clé privé de l'autorité de certification, les données nom, prénom, numéro de carte,date de validité. La transaction se déroule alors hors-ligne (seule la puce est utilisée) :
\begin{enumerate}
\item $T \longrightarrow A$ : authentification
\item $C \longrightarrow T$ : $\{ PK \}_{SK_A}$, $data$, $\{data\}_{SK} $
\item $T \longrightarrow A$ : code?
\item $A \longrightarrow T$ : 1234(par exemple)
\item $T \longrightarrow C$ : 1234
\item $C \longrightarrow T$ : ok.
\end{enumerate}
\pagebreak

\begin{figure}[h!]
\centering
\includegraphics[scale=0.5]{./Images/SDA.eps}
\caption{Diagramme de séquence du mode SDA}
\label{fig:SDA}
\end{figure}

En recopiant les données publiques sur une carte à puce vierge et en ajoutant un programme qui renvoie toujours la valeur ok quel que soit le code confidentiel saisi, on obtient une carte capable de réaliser des transactions hors-ligne comme le ferait l'original.

\subsubsection{Contre-mesure}

\subparagraph{principe d'authentification DDA} :
Par rapport au modèle précédent, on ajoute une paire de clés dans la carte $C$, $PK_C$ et $SK_C$. $Nt$ est un nombre aléatoire généré par le terminal. La transaction se déroule de la manière suivante :
\begin{enumerate}
\item $T\longrightarrow A$ : authentification
\item $C\longrightarrow T$ : $\{PK_B\}_{SK_A}$, $\{PK_C\}_{SK_B}$, $data$, $\{data\}_{SK_C}$ 
\item $T\longrightarrow C$ : Nt
\item $C\longrightarrow T$ : $\{Nt\}_{SK_C}$
\item $T\longrightarrow A$ : code?
\item $A\longrightarrow T$ : 1234(par exemple)
\item $T\longrightarrow C$ : 1234
\item $C\longrightarrow T$ : ok
\end{enumerate}

\pagebreak 

\begin{figure}[h!]
\centering
\includegraphics[scale=0.5]{./Images/DDA.eps}
\caption{Diagramme de séquence du mode DDA}
\label{fig:DDA}
\end{figure}

L'authentification forte est réalisée grâce à un challenge.A l'étape 3, le terminal génère un nombre aléatoire $Nt$ et l'envoie à la carte. A l'étape 4, la carte calcule le résultat du chiffrement de $Nt$ par $SK_C$ et l'envoie au terminal.\\
Ce dernier peut ensuite déchiffrer $\{Nt\}_{SK_C}$ avec la clé publique $PK_C$ et vérifier qu'il obtient bien le nombre $Nt$ qu'il avait envoyé à l'étape 3. Si tel est le cas, il a la garantie qu'il communique bien avec la carte, car seule cette carte dispose de de $SK_C$ et est capable de répondre à ce challenge. De plus, le code de la carte est chiffré par $Kc$, alors que les autres protocoles l'envoient en clair.
 
